ingo wrote:
> in news:414d4389$1@news.povray.org Rune wrote:
>
>> Thanks for your thoughts. I hope you can elaborate a bit on the parts
>> I didn't get.
>
> I'll try, so here's a little demo "scene":

I don't get the logic behind your described system. There seems to be only
one sound attached to each source. A source can play many different sounds,
just not at the same time. How would one specify that in your system? Also,
when pitch and gain are described seperately from the scene file, it seems
difficult to change pitch and gain dependent on variables in the scene.
Pitch and gain can change over time just like position, and it should be
just as simple to do this. I also don't get your conceot of sound_on and
sound_off. You tell your ball object to play a sound while it is off at the
same time, or at least right in the next frame?

I have changed my own system. The code below is working code:

// START POVSOUND
sound_start("soundtest.txt")

sound_set_milliseconds_per_clock(1000,0) // second value is offset
#declare Time = sound_get_time();

#declare EngineSound = "../wavdata/engine.wav";
#declare HoverSound = "../wavdata/hovercraft.wav";

sound_set_gain_once(1000*0, 0.5)
sound_set_dobbler_factor_once(1000*0, 1.0)
sound_set_dobbler_velocity_once(1000*0, 100)

sound_set_listener(Time,camera_location,camera_forward,camera_up)

#declare ship1_starttime = 1000*0;
#declare ship1_endtime = 1000*10;
sound_point_create_once(ship1_starttime,"ship1")
sound_point_destroy_once(ship1_endtime,"ship1")
sound_point_loop_once(1000*0,"ship1",EngineSound)

#if ( is_between(Time,ship1_starttime,ship1_endtime) )
   sound_point_location(Time,"ship1",ship1_translate)
   sound_point_gain(Time,"ship1",2.0) // can easily be changed over time
   sound_point_pitch(Time,"ship1",1.0) // if you use a variable instead of a
number
#end

#declare ship2_starttime = 1000*0;
#declare ship2_endtime = 1000*10;
sound_point_create_once(ship2_starttime,"ship2")
sound_point_destroy_once(ship2_endtime,"ship2")
sound_point_loop_once(1000*0,"ship2",HoverSound)

#if ( is_between(Time,ship2_starttime,ship2_endtime) )
   sound_point_location(Time,"ship2",ship2_translate)
   sound_point_gain(Time,"ship2",1.0)
   sound_point_pitch(Time,"ship2",1.0)
#end

sound_end()
// END POVSOUND

> A value or string that defines the state of the track. In its simplest
> form it could be 'sound_on' or 'sound_off'. Another one could be
> "play_sound", that starts a WAV (sound) and plays it to the end. More
> complex it could be the letters of the alphabet for speech
> syncronisation.

So it is up to the user to figure out how to provide the right trigger
string for every frame? Sounds like it would require lots and lots of
#if(...) #declare trigger = ... #end -structures...

>> Gain and pitch are properties of the object/source, not the sound.
>
> Well in the end also the sound is a property of the object ;) just
> like a texture.

Yes indeed - but that doesn't mean that gain and pitch are properties of the
sound.

>> This means that you can play the same sound at several sources at the
>> same time with different gain/pitch values for each source. If it was
>> a property of the sound, then you couldn't adjust it on a per-object
>> basis, which would be a disadvantage.
>
> By using a sepparate sound render file there is no such disadvantage.
> The advantage is, or may be, that you don't have to render the images
> again if you want to change the properties of a sound linked to an
> object.

Pitch and gain can also be dependent on how the object moves around and be
set for every frame. It would not be easy to manually edit them if they're
specified for each frame. Besides, you don't have to render the images
again. You can just render with "+w1 +h1 -f". It has worked fine for me.

> This also means that
> if the system is general enough, and with less extra work, the user
> could use a different language binding to OpenAL or even a completely
> different sound rendering systems.

Seeing as there are no sound rendering alternatives available yet, his is
not really a priority.

> Maybe the time-line file created by POV-Ray can also be used for
> completely different things.
>
>>> //               name    sound_filename    time
>>> sound_point_loop("ball","wavdata/bump.wav",1000*3.5)
>>>
>>> This one could become:
>>> Track("ball", position, trigger)
>>
>> How is the time where the sound should be played specified? It's
>> insufficient to base it on the frame number, as you might want a
>> sound to start playing at a time value that lies between two frames.
>
> You can have POV-Ray calculate the exact moment of contact and then
> pass that information to the sound rendering system. In the demoscene
> the first frame beyond the moment of contact sets the trigger for the
> sound to play and defines a variable for the delay.

It still sounds like the user have to put a lot of effort into creating the
right triggers...

> You're right the JAVA program can't do much without the proper
> information. This information has to be in the Time-line file,
> generated by POV-Ray and, if you want to sepparate sound and image
> generation files, in the Sound-file.

But how is the time-line file generated? It sounds like you say that it
should be edited manually, even though it contains data for every frame and
thus has a huge amount of data.

Your time-line file sounds very similar to the data format that my system
outputs and which my Java program reads. But the whole point of my macros is
that the user shouldn't have to edit that file manually.

This is what the data-file looks like (the first number on each line is the
time in milliseconds):

0 system gain 0.5
0 system dobbler_factor 1
0 system dobbler_velocity 100
0 system listener <0,0.3,1.2> <0,0,1> <0,1,0>
0 source ship1 create
0 source ship1 loop ../wavdata/engine.wav
0 source ship1 position <0,0,1>
0 source ship1 gain 2
0 source ship1 pitch 1
0 source ship2 create
0 source ship2 loop ../wavdata/hovercraft.wav
0 source ship2 position <1,0.6,10>
0 source ship2 gain 1
0 source ship2 pitch 1
33 system listener <0,0.3,1.18333> <0.00333333,0,1> <0,1,0>
33 source ship1 position <0.418757,0,1>
33 source ship1 gain 2
33 source ship1 pitch 1
33 source ship2 position <1,0.6,9.99123>
33 source ship2 gain 1
33 source ship2 pitch 1
66 system listener <0,0.3,1.16667> <0.00666667,0,1> <0,1,0>
66 source ship1 position <0.836778,0,1>
66 source ship1 gain 2
66 source ship1 pitch 1
66 source ship2 position <1,0.6,9.96493>
66 source ship2 gain 1
66 source ship2 pitch 1

Rune
-- 
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message